Constraints are commonly used in database system to define the conditions under which selected data items are valid. The database management system typically provides one or more mechanisms that permit constraints to be easily associated with specific items of data. Thereafter, the system automatically performs tests to verify that the new or modified data satisfies the specified constraint conditions. In this way, constraints help to insure the integrity and quality of the data stored in the database.
A first class of constraints are often used to support indexing, sorting and referencing. A “not null” constraint may be employed to guarantee the presence of data in a given column, and a “unique” constraint may be associated with table's primary key to prevent the creation of rows with duplicate keys. A “referential integrity” constraint may be associated with a column which holds a “foreign key” to enforce the rule that the value placed in that column must correspond to a primary key value found in another table. These constraints may be imposed automatically by the database management system for columns specified as a table's primary, secondary or foreign keys.
Relational database management systems also typically permit the user to create “check” constraints. Check constraints enhance data integrity by forcing the data to comply with user-specified conditions without requiring procedural logic such as in stored procedures and triggers. A check constraint places data value restrictions on the contents of a column as expressed in a Boolean expression created by the user. Any attempt to modify the column data (i.e. during INSERT and UPDATE processing) will cause the conditions expressed in the check constraint to be evaluated. If the modification conforms to the Boolean expression, the modification is permitted to continue. If not, the attempted modification will fail with a constraint violation.
Check constraints are typically written using a recognizable SQL syntax that defines the constraint conditions. The example below illustrates the manner in which constraints are specified in an illustrative SQL “create table” statement:
create table WORKER (NameCHAR (25) PRIMARY KEY,LocationCHAR (25),AgeNUMBER CHECK (Age BETWEEN 18 AND 65),LodgingVARCHAR2 (15) REFERENCES LODGING (Lodging),SalaryDECIMAL (7,2) NOT NULL,constraintCHECK_SALARY CHECK (SALARY < 50000.00),CommissionDECIMAL (7,2));In the foregoing statement, the Name column is identified as the primary key for the table and is therefor automatically constrained to hold a unique, non-null value. No constraints are specified for the Location column. The Age column is subject to a check constraint that ensures that the Age column will contain only values that range from 18 to 65. The Lodging column is expressed as a foreign key reference and is thus automatically subject to a referential integrity constraint which ensures that the value placed in the Lodging column must correspond to an actual value in the primary key column of another table (the Lodging column of the LODGING table). The Salary column is subject to the constraint that it must not contain a null value. The salary column value must also satisfy the condition expressed in the check constraint named CHECK_SALARY which specifies that the value in the Salary column must be less than 50000.
The constraints discussed above are column-level constraints. Check constraints may also be defined at the table-level after all of the columns of the table are been defined. It is quite common for business rules to require that a specified relationship exist between different columns within a single table. When this situation occurs, the business rule may be expressed as a check constraint at the table-level instead of at the column level. Table level constraints can be used to define required relationships between the values placed in different columns as illustrated by the following SQL example (which could be inserted at the end of the example create table statement listed above) above:
,constraint COMM_BONUS CHECK (Salary>0 OR Commission>0)
This table level constraint is named COMM_BONUS and requires that, within a given row, the value in either the Salary or Commission column must be greater than zero.
Check constraints may be used to enforce business rules directly in each database without requiring additional application logic. Once defined, the business rule is physically implemented and can not be bypassed. Check constraints provide improved productivity for at least the following reasons: (1) no additional programming is required, allowing database administrators to implement business rules as check constraints without involving the application programming staff; (2) check constraints provide better data integrity since validation is always executed whenever the data in the associated column(s) is inserted or updated, and the business rule cannot be bypassed during ad hoc processing and dynamic SQL operations; (3) check constraints promote consistency because they are implemented once and always enforced, whereas rules incorporated into application logic must be executed by each program that modifies the data to which the constraint applies, resulting in duplicative code that is difficult to maintain; and (4) check constraints implemented directly within the database system will typically outperform the corresponding application code.
There is, however, an important class of business rules which cannot be expressed and enforced using the conventional column and table check constraint mechanisms that are typically available to database users. The members of this class of constraints can be defined by a specified relationship between pairs of adjacent rows when adjacency is defined by a specified ordering of the data. Existing technology would require the use of triggers to model such complex constraints. Triggers are stored procedures which are executed upon a certain event, such as a table update, insert or delete operation. However, triggers capable of testing relationships between data in different rows are difficult to write for those without special programming skills, and result in much less efficient processing.